Enfin, exécutez node server.js et visitez http://localhost:3000. Vous devriez voir la page fonctionner avec le bouton.

Essayez-le sur StackBlitz

Si vous cliquez sur le bouton, vous verrez que le nombre ne change pas. L'HTML est complètement statique côté client car nous n'avons pas chargé Vue dans le navigateur.

Pour rendre l'application côté client interactive, Vue doit effectuer l'étape de l'hydratation. Pendant l'hydratation, il crée la même application Vue qui a été exécutée sur le serveur, associe chaque composant aux nœuds DOM qu'il doit contrôler et attache les écouteurs d'événements du DOM.

Pour monter une application en mode hydratation, nous devons utiliser createSSRApp() au lieu de createApp() :

Remarquez que nous devons réutiliser la même implémentation d'application côté serveur. C'est là que nous devons commencer à réfléchir à la structure du code dans une application SSR - comment partager le même code d'application entre le serveur et le client ?

Ici, nous allons démontrer la configuration la plus simple. Tout d'abord, divisons la logique de création d'application en un fichier dédié, app.js:

Ce fichier et ses dépendances sont partagés entre le serveur et le client - nous les appelons code universel. Il y a un certain nombre de choses à prendre en compte lors de la rédaction du code universel, nous allons le voir ci-dessous.

Notre entrée client importe le code universel, crée l'application et effectue le montage :

Et le serveur utilise la même logique de création d'application dans le gestionnaire de demande :

De plus, pour charger les fichiers client dans le navigateur, nous devons également :

Essayez l'exemple complété sur StackBlitz. Le bouton est maintenant interactif !

Pour une application SSR en production, plusieurs considérations supplémentaires doivent être prises en compte :

Prendre en charge les SFC Vue et d'autres exigences de l'étape de build. En fait, nous aurons besoin de coordonner deux builds pour la même application : un pour le client et un pour le serveur.

TIP

Les composants Vue sont compilés différemment en SSR : les templates compilés sont compilés en chaînes, par rapport à des fonctions de rendu de DOM virtuel, pour une performance accrue.

Dans le gestionnaire de requête du serveur, afficher le HTML avec les liens corrects des ressources clientes et autres ressources optimisées. Il peut également être nécessaire de basculer entre le mode SSR et SSG, ou même de mélanger les deux dans la même application.

Gestion du routage, de la récupération de données et des stores de gestion d'état de manière universelle.

Une implémentation complète serait assez complexe et dépend de la chaîne d'outils de build que vous avez choisie. Par conséquent, nous vous recommandons fortement d'adopter une solution plus élevée et orientée afin d'abstraire la complexité pour vous. Ci-dessous, nous présenterons quelques solutions SSR recommandées dans l'écosystème Vue.

Nuxt est une plateforme Vue simplifiée pour développer des applications universelles et peut être utilisée comme générateur de site statique. Nous vous recommandons fortement de l'essayer.

Quasar est une plateforme basée sur Vue qui vous permet de développer des applications pour plusieurs plateformes (SSR, SPA, PWA, mobile, bureau, extension de navigateur) avec un seul code de base. Il fournit également des composants d'interface utilisateur conformes à Material Design.

Vite fournit un support natif pour le rendu côté serveur de Vue, mais il est intentionnellement de bas niveau. Si vous souhaitez utiliser directement avec Vite, consultez vite-plugin-ssr, un plugin communautaire qui fait abstraction de nombreux détails complexes pour vous.

Vous pouvez également trouver un exemple de projet Vue + Vite SSR en utilisant une configuration manuelle ici, qui peut servir de base pour le build. Notez que ceci n'est recommandé que si vous avez de l'expérience avec SSR / outils de build et que vous souhaitez avoir un contrôle complet sur l'architecture de haut niveau.

Indépendamment de votre configuration de build ou de votre choix de framework de haut niveau, il existe des principes qui s'appliquent à toutes les applications Vue SSR.

Pendant le SSR, chaque URL requêtée correspond à un état souhaité de notre application. Il n'y a pas d'interaction utilisateur et aucune mise à jour du DOM, donc la réactivité n'est pas nécessaire sur le serveur. Par défaut, la réactivité est désactivée pendant le SSR pour une meilleure performance.

Vu qu'il n'y a pas de mises à jour dynamiques, les hooks de cycle de vie tels que mountedonMounted ou updatedonUpdated ne seront PAS appelés pendant le SSR et ne seront exécutés que côté client. Les seuls hooks qui sont appelés pendant le SSR sont beforeCreate et created

Vous devriez éviter le code qui produit des effets secondaires qui nécessitent un nettoyage dans beforeCreate et createdsetup() ou dans la portée de . Un exemple d'effets secondaires est la configuration de minuteries avec setInterval. Dans le code exécuté côté client, nous pouvons configurer une minuterie et la démonter dans beforeUnmountonBeforeUnmount ou unmountedonUnmounted. Cependant, étant donné que les hooks de démontage ne seront jamais appelés pendant le SSR, les minuteries resteront à jamais. Pour éviter cela, déplacez votre code d'effets secondaires dans mountedonMounted.

Le code universel ne peut pas supposer l'accès aux API spécifiques à la plateforme, donc si votre code utilise directement des éléments spécifiques au navigateur comme window ou document, ils lanceront des erreurs lorsqu'ils seront exécutés dans Node.js et vice-versa.

Pour les tâches partagées entre le serveur et le client mais avec des API de plateforme différentes, il est recommandé d'envelopper les implémentations spécifiques à la plateforme dans une API universelle ou d'utiliser des bibliothèques qui le font pour vous. Par exemple, vous pouvez utiliser node-fetch pour utiliser la même API fetch sur le serveur et le client.

Pour les API spécifiques au navigateur, la démarche courante consiste à y accéder de manière paresseuse dans des hooks de cycle de vie client uniquement tels que mountedonMounted.

Notez que si une bibliothèque tiers n'est pas écrite en vue d'une utilisation universelle, il peut être difficile de l'intégrer dans une application rendue côté serveur. Vous pourriez être en mesure de la faire fonctionner en simulant certaines des globales, mais ce serait un bricolage et pourrait interférer avec le code de détection de l'environnement d'autres bibliothèques.